IAC in Sys 7
Volume Number: 5
Issue Number: 8
Column Tag: Developer's Notes
Apple's IAC in System 7 
By Frank Alviani, Contributing Editor, Waukegan, IL
Inter-Application Communications - The Future is Rapidly
Approaching
It was just one year ago that my first article on Inter-Application
Communications was printed here in MacTutor. In it and the succeeding two articles
Paul Snively and I described and implemented a facility for allowing programs to be
written that could automatically communicate without bothering the user. Apple has
“validated” that concept by making it a centerpiece of the upcoming System 7.0. This
article will be a short look at the approach taken by Apple, and how it is going to
change the face of the Macintosh forever. (If you work in Word 4.0 with Superpaint
1.1MS, the linked combination gives some hint of the feel of the linked-document
future we are heading towards!) It is NOT an introduction to the actual programming
interfaces.
In addition to the new world Apple is entering, DEC has an analogous concept
called Compound Data Architecture (CDA). The similarities between a suite of
IAC-linked documents on a Mac and a DEC compound document are enough to strongly
suggest that once both are established in the marketplace, it will be reasonably
straightforward to convert between the two systems. This is a non-trivial operational
concern in mixed shops, and important from a marketing viewpoint. I would be mildly
surprised if the two companies didn’t work together to ensure the interconvertability
of their systems.
Apple has taken a layered approach to implementing their IAC facilities; this is
consistent with the approach taken with the other toolboxes and a natural division
based on the intended usage for each layer. The material that appeared here in
MacTutor corresponds to the PPC-toolbox level in the Apple scheme.
Figure 1 shows the layering designed by Apple, intended to show how interfaces
on one layer depend on the next layer down, and how the interfaces at the same level
serve different aspects of a common requirement.
SuperPaint!Me:Write Ups:Apple-IAC Illustrations!Draw(107,129:203,179)
SuperPaint!Me:Write Ups:Apple-IAC Illustrations!Draw(103,56:350,178)
The PPC Toolbox
The lowest level provides the raw messaging tools: direct communication and
“store and forward”. This level is not intended for user-interface usage. It
corresponds most closely to the SAWS IAC system, although the details of the Apple
implementation haven’t been spelled out enough to tell how similar the internals are (I
suspect they are significantly different, since certain of our IAC facilities are placed in
different layers in the Apple software).
This level services two classes of clients: the upper layer of the IAC system
software, and non-event based “chunks o’ code” such as RDEVs, DAs, etc. In a sense,
all code executing on a Macintosh will be on an equal footing, able to talk with any other
code executing at the same time or in the future. It is very important to note that
programs and processes do NOT have to be on the same machine to take advantage of the
PPC facilities.
These tools open up various interesting possibilities:
• Programs would be able to preserve “state information” across sessions by
using the store-and-forward facilities to send messages to their future
incarnations.
• Cooperation between programs on networked machines - well beyond the
capabilities of today’s programs such as Timbuktu - becomes practical. For
example, an artist can be building an illustration for an article, on machine A,
while the article is being written on machine B, and the illustration would be in
place in the article even while being drawn. This could allow unprecedented
cooperation.
• Control panel devices could be used to actually control executing programs, etc.
For example, an intercom is one possible such device.
The “Higher Level Events”
For the programmer, there is a significant extension of the event manager:
“higher level events”. This is intended mostly for “below the surface”
program-to-program requests, many in the form of remote menu-command
executions.
In order for higher level events to be extensible for the future, several fields in
the existing message record have had additional usages layered on top of their existing
definition (in much the same way that the Text Edit toolbox was extended).
As shown in Figure 2, the “message” and “where” fields are redefined when
interpreting a higher level event. The “what2” field - message class - identifies the
protocol that defines how the specific message in the “what3” field is to be
interpreted. How are those message classes going to be assigned so there won’t be
anarchy and inadvertent duplication?
Apple long ago put a workable system in place when it decided to use 4 character
fields to identify resources, application signatures, etc., and that same system will be
used here. Applications will use their signature (‘MACA’, etc.) as the message class
they send; Apple is, as usual, reserving all-lower-case combinations for themselves.
For each class of messages, there are 232 possible messages.
I expect that at first each publisher will independently define sets of messages
that will allow his applications to cooperate. However, there was discussion at the
developers’ conference of perhaps arranging a conference on AppleLink to support the
growth of a set of industry standard, publisher-independent messages. This would be of
enormous benefit to the user, since it would make the development of a universal
scripting language (see the note about AppleScript later) much more likely.
Apple will define the message class roughly corresponding to the File and Edit
menus (calling their protocol AppleEvents™ and using the signature ‘stdr’); the
remaining classes are defined at the discretion of the developers.
The general method of using higher level events is the same that’s used for
existing events - WaitNextEvent to accept events and PostEvent to send them. There are
few options that don’t exist in System 6, but they don’t change current fundamental
techniques.
Certain aspects of this API are still not completely worked out, and will require
considerable care to do properly. For example, we now have the possibility of an
entirely new class of VandalWare: programs maliciously misusing higher level events.
Methods for assuring you are certain of who’s sending a message before you act upon it
will be required.
The Publish-and-Subscribe Interface
The segment of most interest to the user is the “publish-and-subscribe”
support intended to standardize the user-interface approach. This resembles the
technique used in the SAWS IAC driver, and in fact some of the terminology is the same.
The phrase “publish-and-subscribe” was carefully chosen to suggest to users
that there can be a slight delay between when data is published and when it is received;
it also suggests that there can be geographic separation between the data source and
destination.
Apple’s goals for the interface are as follows:
• It must be generalizable - usable for all applications
• It must be scalable - capable of dealing with large amounts of data (for database
or multimedia work, for example)
• It must work cleanly with the existing Mac interface
• It must work over the network to support networked cooperative tasks.
Like the SAWS IAC suggested interface, the fundamental units that are linked are
sections, not documents. A document can have any number of publishing sections and
subscribing sections, and can in fact even subscribe to itself (a wonderful fractal demo
took advantage of this fact!) The IAC toolbox called the Publication Manager includes
support for resources that are required to track the status of these sections, thus
simplifying the programming task. The sections drawn during the demos at the
developers’ conference were all rectangular, but I don’t believe that is required (if it
is it should be generalized).
Like the SAWS IAC driver, the Apple IAC support can be viewed as an extension of
the scrap manager (which is in fact shown in Figure 2). This suggests that
applications need the same types of facilities to support IAC - such as the ability to
handle at least the standard data formats, such as PICT and TEXT. This minimal level of
support alone can go a long way towards making sure that relatively arbitrary
combinations of applications can be “integrated” smoothly; your application doesn’t
need to know how to interpret every data format in the new universe to fit in.
Unlike the SAWS IAC driver, the published data is kept by Apple in external files.
These “pub files” are standard, named files that have their own Finder icon. This
approach provides considerably greater generality: by putting “pub files” on a file
server such as AppleShare, any number of documents can subscribe to the same data.
As with the SAWS IAC driver, the exchange of data from publisher to subscriber can be
asynchronous. The System 7.0 enhancements to the file manager provide file-ID
facilities that are location-independent, so that publication files can be moved around
on a single volume without confusing the client (publisher and subscriber)
applications.
Unlike the suggested user interface for the SAWS IAC driver, Apple’s interface
explicitly requires intervention for data to be published; the suggested action is when
the Save command is invoked. Subscribers in open documents are notified immediately;
subscribers in closed documents are notified when that document is next opened.
Explicit intervention was chosen to simplify the application’s programming model and
to avoid problematic recursive situations. My experience in writing the original
MacTutor sample program suggests that this is a good solution; deciding automatically
when the fresh data is cooked enough to publish is trickier than it looks, and depends a
good deal on the type of data being manipulated. My only suggested extension would be to
also have an explicit “update publication” command as an alternative for programs
where saving is a time-consuming operation, such as databases.
The subscriber, in the Apple model, is a somewhat passive participant; it
normally will just display the data retrieved from the pub file. The user interface
guidelines, however, do support the idea of adornment - style changes made to text, etc.
by the subscribing application before displaying the new data. Scaling and clipping
would be among the appropriate adornments to apply to graphic data.
A very useful facility available to a subscriber is “go to publisher”, possible
because of the backlinks between files. Implemented according to the guidelines, this
transfers control to the publishing application, after the document has been opened if
necessary, and the section has been scrolled into view.
Establishing a linkage between two documents is straightforward:
• The user selects some data; the application calls the publication manager to
create the section-tracking resource.
• The “publish” command is invoked. The application brings up a standard-file
like dialog to name the “pub file”, and then creates it.
• The user goes to the destination document.
• A section is selected to be a subscriber; the application calls the publication
manager to create the section-tracking resource.
• The “subscribe” command is invoked. The application brings up a standard-file
like dialog to select the “pub file”, and then reads it.
• The link is established.
Again, the API is not finalized and there are rough edges that will need to be
smoothed out before System 7.0 is unleashed on the world. For example, there is no
record of the last time a pub file was used, so that there is no easy way to detect
“stale” pub files. If you think junk files accumulate on your hard disk, with only you
living there, think of what some poor AppleShare administrator is looking at...
Conclusions
The design of the IAC support in System 7.0 was very well done. It will be a
reasonable task to incorporate IAC support into existing applications; interface
decisions may be more work for some applications than the actual coding. The facilities
possible are exciting even to jaded developers - the IAC session kept being interrupted
by applause!
In the long run, for anything more complex than a letter to Aunt Sybil, suites of
linked documents are going to become the norm due to the convenience of working with
your personal favorites in each required specialty. This reduces somewhat the
attraction of all-in-one programs such as Lotus’ Jazz and Microsoft Works, although
it may prove that requiring no configuration at all is enough of a feature to support a
worthwhile market.
Applescript is a nebulous future concept that kept surfacing during the
developers’ conference without ever being clearly defined. It sounds like Apple’s
syntactic Holy Grail - a single language syntax that is usable for MPW scripts, SADE
scripts, and the user’s control of the machine as a whole. One planned feature appears
to be that it will have facilities for users to send “higher level event” messages to
programs. This would give them text-based application-independent macro
capabilities, rather like Tempo.
As an example of what all of these facilities together promise, imagine you have
investments in several high-tech stocks that tend to move wildly all over the chart.
Keeping peace in the house requires that you prepare a chart every so often to prove
that poverty isn’t just around the corner, and so you decide to automate the process to
make it less of a nuisance. All it requires is a quick script that does the following:
• At midnight on the 1st of each month, launch your favorite telecomm program
with a program to dial up your data service and download all the prices required.
• Launch your wordprocessor with the basic stock report ready to go, including the
subscribers for the data values and chart of price gyrations.
• Launch your spreadsheet with a worksheet and macro that loads the new data and
charts it. Both the data cells and the chart are publishers, so you save the
worksheet and publish the selected data and chart.
• The stock report updated automatically, so just order it to be saved and printed.
• Close all the applications.
MacTutor programmers, of course, will almost instantly be creating scripts of
far greater complexity, and there will no doubt be a column devoted to AppleScript
programming, but this gives you some idea of the potential that will be available to us
in the near future.
In a couple of years we will probably be working in an environment that has
some characteristics of the traditional mini-computer: (1) Multiple “parallel”
processes, with communications between them, and (2) At least 1 powerful scripting
language that allows flexible automation of repetitive actions - but with the addition of
almost universal data-interchange formats, a huge variety of off-the-shelf software,
and a consistent user interface.
The change from single-program to multi-program workstyle is not going to be
without experimental evolution unprecedented in computer history; we’ve never had
enough power available on a widespread basis to make this new mode of working
feasible. There will undoubtedly be several styles of integration at first, until the
market determines which is most workable, for example. There may be conflicts for a
while between message sets that make it a little rocky to integrate arbitrary
combinations of applications. In spite of these caveats, I am looking forward eagerly to
an IACed universe - and so should you.